When a user interacts with sites on the Internet (hereafter referred to as “service providers” or “relying parties”), the service provider often expects to know something about the user that is requesting the services of the provider. The typical approach for a service provider is to require the user to log into or authenticate to the service provider's computer system. But this approach, while satisfactory for the service provider, is less than ideal to the user. First, the user must remember a username and password for each service provider who expects such information. Given that different computer systems impose different requirements, and the possibility that another user might have chosen the same username, the user might be unable to use the same username/password combination on each such computer system. (There is also the related problem that if the user uses the same username/password combination on multiple computer systems, someone who hacks one such computer system would be able to access other such computer systems.) Second, the user has no control over how the service provider uses the information it stores. If the service provider uses the stored information in a way the user does not want, the user has relatively little ability to prevent such abuse, or recourse after the fact.
To address this problem, new systems have been developed that allow the user a measure of control over the information stored about the user. Windows CardSpace™ (sometimes called CardSpace) is a Microsoft implementation of an identity meta-system that offers a solution to this problem. (Microsoft, Windows, and CardSpace are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.) A user can store identity information with an identity provider the user trusts. When a service provider wants some information about the user, the user can control the release of information stored with the identity provider to the service provider. The user can then use the offered services that required the identity information.
Systems such as Microsoft Windows CardSpace do not establish a single way to manage the information cards. This “lack” of a “standard” is actually a good thing, in that parties that develop card selectors are not limited to a single defined mechanism for storing and using information cards. If a developer decides that a particular piece of data is important to store with an information card, there is no “standard” that prohibits the developer from adding that data to the information card. But it creates a problem in that information cards created by different systems might not be compatible with card managers of other developers.
Information card management tools typically offer the ability to export and import information cards. By exporting and importing cards, users can, if they choose, consolidate their information cards in a single card store that uses a common structure. But such import and export functions can result in the loss of data in the information card. For example, if it turns out that one information card management system stores a particular piece of data that is used only by the card selector developed by that same developer, exporting and importing the information card into a new card management system can result in the loss of that piece of data and the corresponding functionality.
A need remains for a way to provide users with the ability to manage their information cards without losing functionality that addresses these and other problems associated with the prior art.